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Abstract: We propose a routing protocol for wireless networks. Wireless 
routing protocols allow hosts within a network to have some knowledge of the 
topology in order to know when to forward a packet (via broadcast) and when 
to drop it. Since a routing protocol forms the backbone of a network, it is a 
lucrative target for many attacks, all of which attempt to disrupt network traffic 
by corrupting routing tables of neighboring routers using false updates. Secure 
routing protocols designed for wired networks (such as S-BGP) are not scalable 
in an ad-hoc wireless environment because of two main drawbacks: (1) the need 
to maintain knowledge about all immediate neighbors (which requires a discovery 
protocol), and (2) the need to transmit the same update several times, one for 
each neighbor. Although information about neighbors is readily available in a 
fairly static and wired network, such information is often not updated or available 
in an ad-hoc wireless network with mobile devices. Our protocol is a variant of 
S-BGP called SS-BGP and allows a single broadcast for routing updates without 
having the need to be aware of every neighboring router. The protocol is based 
on a novel authentication primitive called Enhanced Chain Signatures (ECS). 



1 Introduction 

The Border Gateway Protocol (BGP) [112] is a Path Vector Routing protocol, 
in which routers repeatedly advertise 'better' routes (along with the path de- 
tails) to their immediate neighbors. On receiving an update, a router checks its 
routing table to decide if this advertised route is better than its existing routes. 
If so, the router updates its table and advertises the new route to all its other 
immediate neighbors. The 'textbook' variant of BGP (hereafter called BGP) 
has many security vulnerabilities |3l4j . For instance, a rogue router could claim 
a shorter route to some destination in order to intercept traffic. Therefore, real 
implementations use a modified variant of BGP called Secure-BGP (S-BGP). In 
S-BGP, routers must have knowledge of immediate neighbors and updates are 
peer-specific. In the context of ad-hoc wireless networks, a node with several re- 
ceivers in its vicinity must first establish the identity of every such receiver who 
is also a forwarder, and then broadcast as many updates. Such control plane 
traffic becomes a bottleneck in scenarios where the wireless devices are densely 
distributed, power constrained and have low data plane traffic. 

In [5], a novel signature scheme called Chain Signatures (CS) is proposed. As 
an application, a secure routing protocol called Stateless Secure BGP (SS-BGP) 



is also presented. The attack scenario described is of a "route truncation attack'!]] 
in wired networks. SS-BGP is as secure as S-BGP and has some advantages. 
The main advantages in their protocol over S-BGP are: (1) updates can be 
broadcast and need not be peer-specific, and (2) routers need not be aware of 
their immediate neighbors. However, such advantages are not overwhelming in 
the scenario presented in [5] because true broadcast channels do not exist in 
wired networks. On the other hand, wireless networks provide true broadcast 
channels without the ability to control or determine who receives this broadcast. 
This feature presents a perfect application scenario for SS-BGP. We extend the 
work of [5] and propose a protocol for wireless routing. The protocol optimizes 
traffic in the control plane by allowing an ad-hoc network of wireless nodes 
to establish routing information in presence of several compromised nodes and 
without any prior knowledge of topology. The protocol is based on an extension 
of CS called Enhanced Chain Signatures (ECS). 

2 Wireless Routing using BGP 

Notation: The following discussion is based on FigureHJ which shows a wireless 
network. The circles represent areas of coverage of the transmitter nodes located 
at their centers, which are represented by small colored discs. The arrows rep- 
resent various messages broadcast by the nodes at the tail. Note that although 
the arrows point to particular directions, every node within the corresponding 
circle is able to receive that message. Each circle has the same radius so that 
any node X is covered by some node Y iff Y is covered by X. Two nodes with 
non-overlapping coverage can communicate by using intermediate nodes as for- 
warders. Each node has a permanently active receiver and a passive transmitter 
that activates when a message is to be sent or a received message is to be for- 
warded. All messages sent by the transmitter are broadcast to anyone in the 
covered area. Senders of broadcasts are uniquely determined via this public key. 
In other words, it is not possible for a broadcasting node to conceal its identity. 

The symbol X Y denotes the string " There is a metric 1 path from Y to 
X" and the symbol X <= denotes the string 11 There is a metric path from X to 
X" . The symbol X — >: m indicates that m is broadcast by X. Sx(m) indicates 
a signature on message m by X using an existentially unforgeable signature 
scheme (we assume that the signature scheme provides message recovery). 

BGP updates: (control plane) Refer to Fig. [1] The following updates are 
sent for routes to A. Each signature (except the first) implies a hop of metric 1. 

S A (A <=) 

S A (A^), S b (A^B) 

Sa(A^), Sb(A^B), Sc(B^C) 

Sa(A*=), S b {A^B), Sc{B<^C), S d (C^D) 

S a (A^), Sb(A^B), Sc(B^C), S e (C<=E) 

Sa(A^), Sb(A^B), S c {B<=C), S d (C^D), S f (D <= F) 



1 Referred to as a path extraction attack in [5] 




> Real routing update 

> Forged routing update 

> Email message 

Fig. 1. A typical scenario for a route truncation attack in wireless networks. 

After the above updates have been transmitted and all signatures are verified, 
each node updates its routing table to contain a tuple (destination, next-hop, 
metric). For instance C's table will contain the entry (A, B, 2). See [1] and Sec- 
tion l3.2l for details on how the nodes construct the table. The nodes use this table 
to decide when to broadcast a received data packet and when to keep silent. If 
a packet arrives from a node that is the next hop for the destination, then the 
packet is dropped, otherwise it is forwarded. 

Forwarding: (data plane) node E broadcasts a data packet destined to A. 
On receiving this packet, node C will activate its transmitter to forward the 
message (since C's routing table shows that E is not the next-hop on route to 
A). Both B and D will receive this broadcast from C but only B will activate 
to forward it further (since D's routing table shows that C is the next-hop for 
destination A). Finally, the broadcast of B is received by A and there is no 
further forwarding. 

Route truncation attack: Although the signatures ensure that fake routes 
cannot be created, they do not ensure that intermediate routes are not truncated. 
As an example, F is an attacker who needs to intercept the above data packet. 
First note that using the above updates, .D's routing table is set to discard data 
packets received from C and addressed to A. Thus, such packets would never 
be received by F. To launch its attack, F pretends to have a shorter route to A 
than C does. To do this, F replaces its routing update broadcast in Step 6 with 
the following: 

F^:S A (A^), S f (A^F) 

On receiving this update, node D will believe that the route to A via F is 
shorter. Consequently, D will update its routing table to forward a data packet 
received from C and addressed to A. This general attack is called route trun- 



cation. In this attack, every data packet sent by E and addressed to A will be 
received by F. Although we only considered an eavesdropping attack, it is trivial 
for F to launch a DoS attack. For instance, if F drops all data plane traffic, it 
can ensure that data packets originating from D and addressed to A never reach 
their destination. 

Secure-BGP Routing: A possible way to disallow this attack is to use 
Sccure-BGP (S-BGP), which is an augmented version of BGP. S-BGP requires 
that updates be recipient specific. Although S-BGP is designed for wired net- 
works, the same concept can be adapted to wireless. S-BGP requires that each 
host be aware of their immediate neighbors (in this context, receivers within its 
coverage). S-BGP assumes that this information has somehow been established. 
Let X and Y denote nodes within E's and F's coverages respectively (but not 
covered by any other node). The S-BGP updates are as follows. 



i. 


A -► 


S A {A <= B) 






2. 


B 


S A (A^B), 


S b (B< 


= C) 


3. 


C -» 


S A {A^B), 


S b {B4 


= C), S C (C^D) 




C -» 


S A (A^B), 


S b {B4 


= C), Sc(C^E) 


4. 


D 


S A (A<=B), 


S b (B< 


= C), S C {C^D), S D (D^F) 


5. 


E -> 


S A (A 4= B), 


S b (B< 


= C), S C (C^E), Se(E 4= X) 


6. 


F 


S A (A^B), 


S b (B <= C), S C (C <= D), S D (D <= F), S F (F <= Y) 



The above protocol is secure from route truncation attack. From an applica- 
tion perspective, the only difference between (ordinary) BGP and S-BGP is that 
while BGP is resistant to every attack except route truncation attacks, S-BGP 
is also resistant to such attacks. 

Stateless Routing: Observe that the S-BGP protocol of Example 2 has 
two major drawbacks: (1) Each router must be "aware" of its neighbors, and (2) 
In the example, router C can no longer broadcast the same message for every 
neighbor. This has scalability problems as follows. Firstly, every transmitter must 
have prior knowledge of all receivers within its coverage, which is clearly prob- 
lematic. Secondly, since each update is peer-specific, even a single route change 
could result in a large number of broadcasts by a node with many receivers in its 
coverage. It would be much simpler if the underlying routing protocol resisted 
route truncation attacks and required each router to broadcast only one short 
message on each update without being aware of its neighbors/receivers. We call 
such a protocol a Stateless Routing Protocol. To avoid the route truncation 
attack in a stateless protocol, given the message in Step 4 of Example 1, attacker 
F should not be able to extract Sa(A <=). Our Contribution: We present a 
stateless routing protocol that resists route truncation attacks. Our proposed 
protocol, called Stateless Secure-BGP (SS-BGP) is a variation of S-BGP and 
provides the following benefits: 

1. It is fully stateless - routers need not be aware of their neighboring receivers. 

2. It is communication efficient - one constant size broadcast per update irre- 
spective of the number of peers. 



2.1 Related Work 



Current research assumes the stateful scenario of Example 2 (S-BGP), and is 
focused on reducing the number of signatures transmitted and/or processing 
time |6|7j . For instance, aggregate signatures have been proposed to keep the 
signature payload to a constant size [6]. The authors of [8] propose the use 
of Signature Amortization [7J coupled with aggregate or sequential aggregate 
signatures [9] to reduce the size of update messages and the signing time. The 
authors of [10] propose the use of identity-based sequential aggregate signatures 
(IBSAS) to authenticate routing updates. However, the above works assume a 
stateful environment, where information about immediate peers is known, and 
do not consider the route truncation attack described above using Example 1 
(where information about the next-hop is not available to the current signer). 
Specifically, the above works do not consider the attack where given the message 
in Step 6, router F is able to compute the message sent in Step 1 without 
extracting the private keys of all of {A, B, C, D, E}. 

3 The Building Blocks 

Notation: We first develop some notation to deal with ordered elements, which 
we call sequences. 

1 . A sequence is similar to a set except that the order of its elements is impor- 
tant. Elements of a sequence are written in order, and enclosed within the 
symbols (,). For instance, (2/1,2/2,2/3) is a sequence. The symbol 9 denotes 
the empty sequence with zero elements. 

2. Let £ a = (2/1, 2/2, ■ ■ • ! Uk) be some non-empty sequence. For any other se- 
quence ii,, we say that £b ~< £ a if and only if lb = (2/1, 2/2, ■ • ■ , Hi) and 
< i < k. We say that two sequences {£ a , £b] overlap if there exists a non- 
empty sequence £ such that £ < £ a and £ -< £\>. For instance, {(2/1, 2/2) , (ui)} 
overlap, while {(2/1,2/2) , (2/2)} do not. 

3. For any two sequences £ a , £b, the symbol £ a U £b denotes the set of elements 
that belong to at least one of {£ a ,£b}- Similarly £ a n £b denotes the set of 
elements that belong to both £ a and £b- We denote by £ a £b to be the set 
of elements from the largest sequence £ such that £ < £ a and £ ~< £b- Clearly, 
for two overlapping sequences {£ a ,£b}, we have that £ a £b 7^ 0. 

4. Collapsing Rule: Any sequence ((2/1, 2/2, ■ ■ ■ Hi) , 2/i+i) is equivalent to the se- 
quence (2/1,2/2, ■ ■■Ui+i)- 

3.1 Enhanced Chain Signatures 

In [5], a novel signature scheme called Chain Signatures (CS) is presented, which 
is essentially a combination of Boneh et al.'s aggregate signatures and Verifiably 
Encrypted Signatures (VES) [H). The nice property about CS is that in addi- 
tion to ordinary properties, they also provide truncation resilience. In the model 
of [5], every signer signs the same message. We consider an extension of CS, 



called Enhanced Chain Signatures (ECS) in which each signer may sign differ- 
ent messages. Note that CS can be extended to allow signers to sign different 
messages by using another existentially unforgeable signature scheme in conjunc- 
tion as discussed in the original paper. However, ECS offers better performance 
and a cleaner security definition. ECS is described below. 

Algorithms: ECS are defined by 3 algorithms: ECS-(KeyGen, Sign, Verify). 

ECS-KeyGen(T) takes a parameter r. It outputs a private-public key pair 
{x,y). 

ECS- Verify^, a) takes as input £ = ((mi, y±), (rn.2, 2/2), ■ ■ ■), a finite sequence 
of (message, public key) pairs, and a string a. 

1. If £ = 9 and a — 1, the algorithm outputs VALID. 

2. \i£ = B and a ^ 1, the algorithm outputs INVALID. 

3. If any public key repeats in £, the algorithm outputs INVALID. 

4. If this step is executed, the algorithm invokes a deterministic poly-time 
procedure after which it outputs either VALID or INVALID. 

ECSSign(xi,yi,mi, £j, o-j) takes five inputs, which can be grouped into three 
parts: (1) a (private key, public key, message) tuple (xi, mj, (2) a sequence 
tj = ((mi,yi), (m 2 ,y 2 ), • • ■ , (%, yj)) of j (message, public key) pairs for 
j > 0, and (3) a string o~j (a purported chain signature on £j). 

1. If yt € {yi, 2/2, • ■ ■ j yj}, the algorithm outputs ERROR. 

2. If ECS- Verify (£7, uj) = INVALID, the algorithm outputs ERROR. 

3. If this step is executed, the algorithm computes a chain signature Uj on 
£i, where £i = (£j, (mi,yi)). It outputs <7j. 

A string a is an ECS signature on a sequence £ if ECS-Verify(^, a) — VALID. 

Difference with a CS scheme: If for every sequence ((mi, j/i), (m,2, j/2), • • •) to be 
signed, holds Vz : m, = mi, then the ECS scheme is also a CS scheme. 

Security Model: We define the security of ECS in the adaptive known key (AKK) 
modelo This notion is called security under adaptive known key and chosen 
message attack. We define two variants using a parameter ui such that setting 
u> = 1 results in the weaker variant. 

Game ECS-UNF w (r) 

Setup. The challenger gives the security parameter r to the adversary A, who 
then selects a game parameter n (the number of public keys) and an n 
bit string extr (the Is of extr denote the indexes of the public keys that 
the adversary wants to extract). Let ea;ir[i] denote the i th bit of extr. On 

2 We note that our actual construction is actually secure in the stronger model of 
Adaptive Chosen Key (ACK) attacks, where the adversary inserts/replaces chosen 
public keys at chosen locations (and hands over the corresponding private keys to 
the challenger). In the extended model, such public keys are considered equivalent 
to those that have been extracted. 



receiving (n,extr), the challenger generates n key-pairs (xi,yi) <— ECS- 
KeyGen(-r) (1 < i < n) and gives the set Y = {yi}i<i< n of n public keys 
along with set X = {xi\extr[i] = l}i<i< n of extracted private keys to A. 
In the following, we denote by L the set of all non-empty sequences of pairs 
(m, y) £ {0, 1}* x Y such that no y is repeated. 
Queries. Working adaptively, A makes queries as follows: 

1. Extract: This query consists of a public key y £ Y. If oj = 1, the chal- 
lenger responds with _L. Otherwise, it responds with the private key 
corresponding to y. 

2. ECS-Sign: This query consists of a sequence I £ L. The challenger re- 
sponds with an ECS signature on £. 

Output. A outputs a pair (£a, &a) £ L x {0, 1}*. 

Result. A wins if ECS- Verify (i^, a a) = VALID and £a is non-signable (Def.EJ). 

Definition 31 (Non-signable Sequence) In the game, let Yx C Y and Lg C 

L be the set of inputs to the extract and ECS-sign queries respectively (Note: 
{yi\extr[i] = l}i<j< n C Yx). For any l& £ L, define the set La = {£i\£i £ 
Ls A {£a,£{} overlap}. £a is non-signable if: 

1. Ia i L s 

2. The set {(mi,yi)\(mi,yi) £ Ia^Vi £ Y x } is non-empty. 

3. For every £ L A , the set { (rrij , y 3 ) \ (nij , y 3 ) £ Ui A )\(ti Q£a) A yt £ Y x } 
is non-empty. 

In the following, we also consider the use of hash functions in the construction. 

Definition 32 The ECS scheme U is (n,T,t,q s ,q e ,qh,e)-TJNF-u)-secure for 
uj £ {1,2} if for game parameters r and n, there is no adversary A that runs for 
time at most t; makes at most (q s ,QetQh) chain-sign, extract and hash queries 
respectively; and wins Game ECS-UNF w (t) with probability at least e. 

Discussion: Roughly speaking, the above security notion implies security un- 
der two types of forgeries [S]. We illustrate this with an example. The first 
forgery (called ordinary forgery) occurs when the adversary manages to out- 
put a valid ECS signature on a sequence £ = ((mi,yi), (ni2,y-i)) after making 
an ECS-sign query on £\ = {(m\,yi)) but without making an extract query 
on ?/2- This is the type of forgery that all multisignatures schemes (including 
the ones discussed in Section I2.ip resist. The second type of forgery in ECS 
(called extraction forgery) occurs when the adversary manages to output a valid 
ECS signature on £ = ((mi, j/i), (rri2, 2/2)) after making an ECS-sign query on 
£ 3 = ((mi, yi), (7712,2/2), (^3, 2/3)) but without making an extract query on y 3 
and one of {2/1,2/2}- A scheme secure against an extraction forgery is said to 
be truncation resilient. Note that none of the schemes mentioned in Section 12.11 
consider extraction forgery in their security definitions. 

Construction: A construction of ECS is given in Appendix lAl 



3.2 The BGP Routing Protocol 

It is helpful to refer to Figurc[T]in the following discussion. As mentioned earlier, 
this protocol is not resistant to route truncation attacks. 

Consider a routing update for a particular destination. This routing update 
propagates in a structure represented by a tree rooted at the destination node 
with routers at level i representing nodes of the tree at level i of the update (the 
root node is considered to be at level 1). For any positive integer i, consider an 
arbitrary node at level i + 1 of the tree. Label as R\, R%, ■ ■ ■ , Ri+i, the sequence 
of nodes in the path from the root node to this node (both inclusive). Denote 
by Sigrii, Verify^ the sign and verify functions of node Ri under an existentially 
unforgeable signature scheme. Rq is a constant string used for notational conve- 
nience. BGP has two phases: Initialize and Update. 

Initialize Let t\ be a timestamp when this update is initiated. The initiator 
(Ri) sets mi «— (Rq, Ri, t\); Sigi <— Sign 1 (mi); and U\ <— ((mi, Sigi)). It 
broadcasts U\. 

Update On receiving update [/j, node Ri+i sets m i+ i <— (i? i; , ti+i), where 
ti + \ is a timestamp when this update was received. The update phase consists 
of two stages: 

1. Validation: Parse Ui as ((mi, sigi), (m-2, sig2) 1 ■ ■ ■ , (m.j, sigi)). Then en- 
sure the following: 

(a) For each j £ [l.i] : n%j is of the form (i?j_i, Rj,tj). 

(b) For each j £ [l.i] : R j+ i f {Ri,R 2 , .. .,Rj}. 

(c) The route to Ri given by the sequence (R\, i?2, ... ,Ri) is either new 
or better than an existing route. 

(d) For each j £ [l.i] : The difference in timestamps, tj+i — tj is within 
a pre-defined threshold t. 

(e) For each j £ : Verify 'Arrij, sigj) = VALID. 

Abort if any of the above checks fail, otherwise, update routing table 
and proceed to the next step. 

2. Propagation: Set sig i+1 <- Sign i+1 (m i+ i); U i+1 <- ([/j, (m i+ i, siflf i+ i))); 
and broadcast f/j+i. 

If the update has been successfully been validated and propagated, then we say 
that the update has been accepted. 

Correctness: Step 1. ensures that the update is of the correct format. If all nodes 
are honest then the only steps where validation can fail are 

1. Step ii., when R4+1 £ {Ri, R2, ■ ■ ■ , Ri}- For instance, referring to Figure HJ 
when C's routing update reaches B. 

2. Step iii., when the existing routing table has a better route. 

In either case, the protocol behaves correctly and implements BGP [T]. 

Security: The security is captured in the Validation stage as follows: 

1. Step iv. prevents replay attacks. 

2. Step v. ensures each node j £ [l.i] accepted this update. 



Weakness: The weakness in this protocol is that although Step v. ensures that 
each node j £ [L.i] accepted this update, it does not ensure that these are the 
only nodes that accepted this update. Specifically, it does not prevent the route 
truncation attack discussed in Section [21 For instance, when R4+1 receives this 
update, it cannot ensure that Ri received this update from R4-1, since Ri could 
have truncated several intermediate entries. Due to this weakness, the above 
protocol is not suitable for use in an real- world environment. 

Advantages: The primary advantage is that of statelessness - any node Ri never 
needs knowledge of i?,+i. Therefore, there is no need to establish knowledge of 
immediate neighbors in order to use the protocol. Secondly, since update Ri is 
independent of R4+1, the same update can be used by several nodes at level i + 

4 Stateless Secure BGP using ECS 

As in Section [221 let (Rx, R%, . . .) be any arbitrary sequence of nodes that would 
be affected by a given updat^l, and U be the timestamp at which the update 
originated/arrived at node i. Let (xi, yi) be the (private, public) key-pair of node 
Ri under an ECS scheme. Assume that every node has a distinct public key. The 
SS-BGP protocol is as follows. 

Initialize The initiator (i?i) sets: mi <— ti; L\ <— ((mi, Ri)}} £1 — (mi,yi); and 
(j 1 <— ECS-Sign(a;i, yi, l\, 9, 1). Finally it sets C/i <— (L\, 01) and broadcasts 
the update J7iQ 

Update On receiving update Ui = (Li,o~i), node Ri+\ sets m 1+ i <— ti + \ and 
does the following: 

1. Validation: Parse Li as ((mi, i?i), (m-2, R2), ■ ■ ■ , Ri))- Then ensure 
the following: 

(a) For each j £ : nij is of the form tj. 

(b) For each j £ [l.i] : R j+1 £ {Ri,R 2l Rj}. 

(c) The route to R\ given by the sequence (Rx,R%, . . . ,Ri) is either new 
or better than an existing route. 

(d) For each j £ [L.i] : The difference in timestamps, tj + \ — tj is within 
the pre-defined threshold t. 

(e) Construct the sequence ti = ((mi, y%), (7722,2/2)) •••> and 
test if ECS- Verify^;, a*) = VALID. 

Abort if any of the above checks fail, otherwise, update routing table 
and proceed to the next step. 

2. Propagation: Set L i+1 <- (Li, (m i+ i, R%+i)); ii+i <- (£i, (m i+1 ,y l+1 )); 
a i+1 <— ECS-Sign(x i+ i, y i+ x,m i+ i, £ it a^. Finally, set U i+ i <- (L i+1 ,a i+ i) 
and broadcast L^+i. 

3 Note that there will be many such distinct sequences for the same update and Ri 
would be the first node in all these sequences. 

4 Our basic BGP variant only needs to validate the timestamp. However, if any addi- 
tional information must be inserted at node i, this can be included as part of m;. A 
possible example of such additional information is the GPS coordinates of i. 



Correctness: Referring to the basic BGP protocol of Section I3T21 the only dif- 
ference is in Step v. Assuming that the validation in this step always passes, the 
above protocol then implements BGP in presence of honest users. 

Security : The only difference from the protocol of Section \3 . 21 regarding security 
is in Step v., where ECS- Verify is used. First note that if the ECS scheme 
is UNF-1 secure then the protocol indeed ensures that each node j £ 
accepted this update. Now consider Figure [1] Then the nodes in the path of the 
update received by F for destination A are (A, B,C, D). The update is of the 
form Ud — (Ld,o~d), where Lb — {(tA,A)(tB,B)(tc,C)(trj,D)). Consider the 
only two possible attacks by F. 

1. Route Truncation Attack: As an example, consider the attack of Sec- 
tion^ where given the update 

[S A (A^), S b (A^B), Sc(B^C), S d (C^D)}, 

attacker F extracts the update [Sa(^4 <*=)]. In SS-BGP, this translates to F 
extracting the ECS signature a a on £a given the ECS signature ob on £b- 
Under the UNF-1 security notion of ECS, this is not possible unless F has 
extracted all the private keys of {B, C, D}. 

2. Repeating Attack: F simply repeats (forwards) the message received from 
D and masquerades as D in the hope of making the route at least one 
hop shorter. This attack is unavoidable using all existing methods for wired 
networks, including those based on S-BGP and the ones discussed in l2.11 An 
attacking node can always forward messages without modification so that its 
presence is never detected. However, in the case of wireless networks, there 
are possible ways to detect this attack. 

Under our original assumption that senders of broadcasts can be uniquely 
identified, the repeating attack is not possible. Note that this assumption is 
quite strong. A possible way to avoid this assumption would be to encode the 
GPS coordinates of each node in the update along with the timestamp (see 
Footnote [4} . Using this technique, it is possible to determine if a message 
was sent via a repeater or not. 

Communication Overhead : Assuming that public keys can be uniquely identi- 
fied by IP addresses, the sequences ti can be constructed at the receiver's end by 
knowing the timestamps {b\, t%, . . . , ti) and IP addresses (Ri, R2, ■ ■ ■ , Ri)- Con- 
sequently, the only overhead in this protocol is that of one single chain signature 
(Ti, which is an element of G\ and is less than 30 bytes using the parameters 
of [5] . Contrast this with basic BGP or S-BGP, both of which incur an overhead 
of i signatures. 

Storage and Performance: The keys are elements of G\ and can be stored in < 30 
bytes [5]. The benchmarks of [11] indicate the following performance estimates 
of the above protocol (assuming n nodes in the path) : 



1. Update Propagation: one exponentiation and addition in G\, and one 
computation of TL (total < 2ms). 

2. Update Verification: n pairing computations and multiplications in G2, 
and n computations of TL (giving < 1 second for n = 100). 

To conclude, SS-BGP based on ECS is at least as secure and as computa- 
tionally efficient as S-BGP based on the signature schemes of 6 10 without the 
extra overhead of neighbor discovery, multiple signature computation, multiple 
broadcasts and multiple signatures in each broadcast. 

Multiple Updates Aggregation : In the above description, we assumed that each 
advertisement Ui contains only one route and is transmitted instantaneously. In 
the real world, each advertisement contains multiple routes and is sent periodi- 
cally. Fortunately, the ECS scheme allows for signature aggregation and aggregate 
verification where a large number of ECS signatures are verified at once [5J. 

5 Conclusion 

In this paper we presented an efficient stateless routing protocol for wireless 
networks called Stateless Secure BGP (SS-BGP). Our protocol is based on or- 
dinary BGP, which allows forwarding nodes to build a routing table without 
prior knowledge of neighboring forwarders, and allowing a single broadcast per 
node irrespective of the number of neighbors. We call such a protocol stateless. 
However, BGP used in this manner does not resist route truncation attacks, and 
is therefore useless for practical purposes. In order to prevent such attacks, mod- 
ern implementations use a stateful variant of BGP called Securc-BGP (S-BGP). 
S-BGP requires forwarding nodes to have prior knowledge of their immediate 
neighbors and requires as many broadcasts per node as there are neighbors. 
Although sufficient for wired networks, S-BGP has scalability issues in mobile 
ad-hoc wireless networks with low data plane traffic because of the need to 
constantly keep updated information about neighbors in order to keep updated 
routing tables. 

SS-BGP is based on stateless BGP and resists route truncation attacks. The 
main ingredient of our protocol is an authentication primitive called Enhanced 
Chain Signatures (ECS), which is an extension of Chain Signatures (CS) of [5]. 
The main property of CS and ECS that differentiates them from other multisig- 
nature schemes is that in addition to standard authentication, both primitives 
also provide truncation resilience (see [5] for a formal discussion of this con- 
cept). In our context, this property translates to route truncation resilience in a 
stateless implementation of BGP. 

In summary, S-BGP incurs the following overhead: (1) neighbor discovery, 
(2) multiple signature computation, (3) multiple broadcasts, and (4) multiple 
signatures in each broadcast. Although the signature schemes of [6 10 are able 
to address issue (4), they do not address the remaining three. SS-BGP based on 
ECS is as secure and computationally efficient as S-BGP based on the signature 
schemes of [6110] without any of the above overheads. This feature makes SS- 
BGP particularly suited for use in a wireless environment. 



References 



1. Y. Rekhter, T. Li, and S.Hares. RFC 4271: A Border Gateway Protocol 4 (BGP-4), 
jan 2006. 

2. Jennifer Rexford, Jia Wang, Zhen Xiao, and Yin Zhang. Bgp routing stability of 
popular destinations. In A CM SIGCOMM IMW (Internet Measurement Work- 
shop) 2002, 2002. 

3. S. Murphy. RFC 4272: BGP Security Vulnerabilities Analysis, January 2006. 

4. Ratul Mahajan, David Wetherall, and Tom Anderson. Understanding bgp miscon- 
figuration. In SIGCOMM '02: Proceedings of the 2002 conference on Applications, 
technologies, architectures, and protocols for computer communications, pages 3- 
16, New York, NY, USA, 2002. ACM Press. 

5. Amitabh Saxena and Ben Soh. One-way signature chaining: A new paradigm for 
group cryptosystems. International Journal of Information and Computer Secu- 
rity, 2(3):268-296, 2008. 

6. Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verifi- 
ably encrypted signatures from bilinear maps. In Eli Biham, editor, EUROCRYPT, 
volume 2656 of Lecture Notes in Computer Science, pages 416-432. Springer, 2003. 

7. Jung Min Park, Edwin K. P. Chong, and Howard Jay Siegel. Efficient multicast 
packet authentication using signature amortization. In SP '02: Proceedings of the 
2002 IEEE Symposium on Security and Privacy, page 227, Washington, DC, USA, 
2002. IEEE Computer Society. 

8. Meiyuan Zhao, Sean W. Smith, and David M. Nicol. Aggregated path authentica- 
tion for efficient bgp security. In CCS '05: Proceedings of the 12th ACM conference 
on Computer and communications security, pages 128-138, New York, NY, USA, 
2005. ACM Press. 

9. Anna Lysyanskaya, Silvio Micali, Leonid Reyzin, and Hovav Shacham. Sequential 
aggregate signatures from trapdoor permutations. In Christian Cachin and Jan 
Camenisch, editors, EUROCRYPT, volume 3027 of Lecture Notes in Computer 
Science, pages 74-90. Springer, 2004. 

10. Alexandra Boldyreva, Craig Gentry, Adam O'Neill, and Dae Hyun Yum. Ordered 
multisignatures and identity-based sequential aggregate signatures, with applica- 
tions to secure routing. In CCS '07: Proceedings of the 14th ACM conference 
on Computer and communications security, pages 276-285, New York, NY, USA, 
2007. ACM. 

11. Giuseppe Ateniese, Kevin Fu, Matthew Green, and Susan Hohenberger. Improved 
proxy re-encryption schemes with applications to secure distributed storage. Cryp- 
tology ePrint Archive, Report 2005/028, 2005. 

12. Dan Boneh, Ben Lynn, and Hovav Shacham. Short signatures from the weil pairing. 
J. Cryptology, 17(4):297-319, 2004. 

13. Dan Boneh and Matthew K. Franklin. Identity-based encryption from the Weil 
pairing. SI AM J. Comput., 32(3):586-615, 2003. 

14. Paulo S. L. M. Barreto, Hae Yong Kim, Ben Lynn, and Michael Scott. Effi- 
cient algorithms for pairing-based cryptosystems. In CRYPTO '02: Proceedings 
of the 22nd Annual International Cryptology Conference on Advances in Cryptol- 
ogy, pages 354-368, London, UK, 2002. Springer- Verlag. 

A Construction of ECS 

The following construction of ECS is an extension of the CS scheme of [5] . 



1. Bilinear Maps: Let G\ and G 2 be two cyclic multiplicative groups both 
of prime order q such that computing discrete logarithms in G\ and G2 is 
intractable. A bilinear pairing is a map e : Gi x G\ >—» G 2 that satisfies the 
following properties |12ll3l6j . 

(a) Bilinearity: e(a x , b v ) — e(a, b) xy Va, b £ G\ and x, y £ Z q . 

(b) Non-degeneracy: If 17 is a generator of G\ then e{g,g) is a generator of 
G 2 . 

(c) Computability: The map e is efficiently computable. 

In a practical implementation, Gi is a subgroup of the (additive) group of 
points on the elliptic curve and G2 is the multiplicative subgroup of a finite 
field. The map e is derived either from the modified Weil pairing [12113] or 
the Tate pairing |14j . The security of our protocol depends on the hardness of 
the Computational Diffie-Hellman (CDH) problem in Gi, defined as follows: 
given g x , g y £ G\ for some generator g and unknowns x,y, compute g xy £ 
Gi 0. 

2. Common Parameters: Let e : Gi x G\ 1— > G2 be a bilinear map over 
cyclic multiplicative groups (Gi,G2) of prime order q and g £ G\ be a 
generator of G\. The prime q is chosen so that the CDH problem in Gi is 
requires w 2 T operations for some security parameter r. See [B] for details. 
Let H : {0, 1}* 1— ► Gi be a hash function. In the rest of this section, these 
parameters will be considered common and public. 

3. The Algorithms: The following are the three algorithms in the scheme. 

ECS-KeyGen. Each user j generates Xj «— % q . The private key of j is Xj. 

The corresponding public key is Yj = g x i £ G\ . 
ECS-Sign. Let £, = {(mi, Yi), (1712, Y2), ■ ■ ■ , (mi, Yi)} be some sequence of 

i distinct (message, public key) pairs. An ECS signature on sequence £, 

is an element Ci £ G\, where: 

i 

<*i = II (m 2) Y 2 ), (rn^Yj)))^, 

j'=i 

and do = Id - The ECS signature cr^ = ECS-Sign(xi, yi, TOj, £j— 1, Cj— 1) 
is computed by user i e {1,2,.. .} as 

a t ^-a^ 1 -U{{{m 1 ,Y 1 ),{m2,Y2),...,{m l ,Y i ))) x \ 

ECS-Verify(£i, cri). To verify the signature cr, on £j = ((mi, Jj), (m2, ^2), ■ ■ • , (mj, Yj)), 
check that all Y^s are distinct and the following holds: 

i 

e(ffi,5) = II e(W(((mi,Fi), (m 2 ,F 2 ), . . (m,-, F,))), F,). 
i=i 

4. Security: The CS scheme of [S] is shown to be UNF-l-secure. We observe 
that the same proof of [5] works for the above ECS construction without 
any modification in the simulator. Hence, the above ECS construction is also 



UNF-l-secure in the random oracle model under the computational Diffie- 
Hcllman (CDH) assumption in bilinear maps. We refer the reader to [5] for 
the original proof. A sketch will be given in the full version of this paper on 
a preprint archive. 
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